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TITLE OF THE INVENTION 



Bearer Connection Signaling In A Distributed Architecture 

This patent application claims priority from two U.S. 
Provisional Patent Applications, Serial No. 60/404,715, 
entitled "Control of VoATM Bearer Connections in a 
Distributed Architecture Using VoIP Signalling" filed 
August 20, 2002 and Serial No. 60/410,250 entitled 
"Method and apparatus for Employing Internet Protocol 
Address within an ATM Network" filed September 12, 2002. 

BACKGROUND 

Field Of The Invention. 

The present invention is directed to a telecommunication 
network for the transmission of voice information and 
particularly to signaling a bearer connection having a 
different protocol than the telecommunication network. 

Related Information . 

In a distributed architecture, the backbone of the 
network is provided by one provider and the remaining 
functionality is provided by other providers connecting 
to the network. Problematically, the network employs one 
protocol while the connecting provides another, which 
frustrates the signaling of bearer connections of the 
different signaling protocol. Thus, there is a great 
customer demand for a solution that signals existing 
customer bearer connections from the resident network 
architecture . 

Take for example an architecture that employs control 
plane signaling traditionally associated with voice-over- 
internet protocol (VoIP) bearer connections. Such an 
architecture is not set up to signal bearer connections 
of another protocol. On the other hand, it is not 
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atypical for customers to utilize an asynchronous 
transfer mode (ATM) protocol. 

The problem is illustrated in more detail with reference 
to Figure 1, wherein a distributed architecture 100 
encompasses access at the edge of the network 101, 
interfaces to the core transport and centralized network 
control. At the heart of the distributed architecture 100 
is a switch 102, which may be a soft switch (a software 
application emulating a switch) , which provides service 
control and network intelligence. 

Trunk gateways 104 provide the capability to inter-work 
bearer payload between legacy TDM trunks and packet based 
virtual trunks. Line or Access gateways 106 provide a 
similar interworking capability for subscriber lines. An 
integrated access device (IAD) 108 is a customer- located 
platform that delivers integrated voice and data 
services . 

The Element Management system 110 provides open standards 
based management interfaces and state of the art 
Graphical User Interface (GUI) for the management of 
network elements. Servers 112 provide support 
functionality such as authentication and announcement 
services, and a server database 114 provides the 
information for the servers. An Operator Service 
Provider (OSP) 116 may be provided to establish third 
party application access via an APIs/CORBA PARLAY and 
resource servers 118 may be provided for adding 
additional resources . 

In the distributed architecture 100 of Figure 1, the 
signaling interface between a controlling switch 102 and 
gateways 104, 106, 108, also referred to as media 
gateways (MG) in the art, is commonly referred to as a 
vertical interface as it transcends the call 
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control/application plane and the bearer/routing plane. 
In order to support a clear separation of call and bearer 
controls, a typical distributed architecture employs an 
open standard Gateway Control Protocol (e.g.; MGCP or 
MEGACO/H. 248) across this vertical interface as shown 
generally by reference numeral 110. 

In the example shown, the core network employs control 
signaling in accordance with the Internet Protocol. 
However, the user community has defined standard Gateway 
Control packages (namely Media Gateway Controller 
Protocols, MGCP/MEGACO, and SIP) that must be used on the 
vertical interface in order to signal the control bearer 
connections. Also defined is a standard use of Session 
Description Protocol (SDP) parameters. In other words, 
such a distributed architecture 100 is not capable to 
signal the bearer connections directly. 

What is needed, therefore, is a means or method for a 
telecommunications network to signal the bearer 
connection. What is needed is to signal a bearer 
connection of another protocol. A solution could be used 
which seamlessly migrates signals from one signaling 
protocol to another. In a specific application, VoIP 
signaling a VoATM bearer connection is needed. 

OBJECTS AND SUMMARY OF THE INVENTION 

One exemplary object of the invention is to provide a 
telecommunications network capable to signal a bearer 
connection. 

Another exemplary object of the invention is to signal a 
bearer connection of another protocol. 
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Yet another exemplary object of the invention is to 
seamlessly migrate signals from one signaling protocol to 
another . 

5 Still anther exemplary object of the invention is to 
provide VoIP signaling to a VoATM bearer connection. 

These and other objects are achieved by the present 
invention in which a signaling method of a bearer 

10 connection coupled to a telecommunications network is 

provided, wherein the telecommunications network employs 
a first protocol and the bearer connection employs a 
second protocol. At least a portion of the first 
protocol is mapped to the second protocol. A first signal 

15 of the first protocol is inserted into a second signal of 
the second protocol according to the mapping, wherein the 
first signal of the first protocol is employed in the 
control of the bearer connection. 

20 According to the objects of the invention, there is also 
provided an apparatus for signaling a bearer connection 
coupled to a telecommunications network, wherein the 
telecommunications network employs a first protocol and 
the bearer connection employs a second protocol. A 

25 translator translates, according to a predetermined 

mapping, between a first signal of the first protocol and 
a second signal of the second protocol . A gateway 
inserts the first signal translated by the translator 
into the second signal, wherein the first signal is 

3 0 employed in the control of the bearer connection. 

BRIEF DESCRIPTION OF THE DRAWINGS 

35 The present invention shall be described in reference to 
the following drawings which illustrate at least one 
example of the invention. 
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Figure 1 is a block diagram of one example of a 
distributed telecommunications/networked architecture; 

Figure 2 is a flow diagram according to one embodiment of 
5 the invention; 

Figure 3 is an address mapping according to one 
embodiment of the invention; 

10 Figure 4 is a port mapping according to one embodiment of 
the invention; 

Figure 5 is a block diagram according to one embodiment 
of the invention; 

15 

Figures 6A, 6B are system and flow diagrams respectively 
according to one embodiment of the invention; and 

Figure 7 is a flow diagram according to one embodiment of 
20 the invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

25 The present invention shall be discussed in reference to 
the flow diagram 200 shown in Figure 2, which illustrates 
a method for signaling a bearer connection of another 
protocol coupled to a telecommunications network. The 
telecommunications network employs a first protocol, 

30 which in the exemplary embodiment is VoIP. The bearer 
connection employs a second protocol, such as VoATM. 
However, its shall be understood that the invention is 
not so limited to any particular protocol, but 
encompasses at least signaling a bearer connection of a 

35 different protocol than the telecommunications network. 

In step 202, the first protocol is mapped to the second 
protocol, or vice versa. Of course, the invention may 
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map the entire first protocol to the second protocol, or 
at least a potion thereof. 

As heretofore discussed, it is typical for a distributed 
5 architecture to employ an open standard Gateway Control 
Protocol, such as MGCP or MEGACO/H . 24 8 , across the 
vertical interface. Here now is an example of a mapping 
according to the invention to control VoATM connections 
using packages more commonly associated with VoIP 
10 connections. In Table I below, there is shown a Megaco 
Real-Time Transport RTP Package (RTP) mapped to an ATM 
Package (ATM) . 



Package 
Definition 


VoIP 


VoATM 
mapp j. ng 


Comment 


Properties 


N/A 


N/A 




Events 


N/A 


N/A 




Signals 


N/A 


N/A 




Statistics 


Packets 
sent 
vps ; 


Cells sent 
(cs) 


The packets sent field 
(rtp/ps) is populated 

t*7t t~ Vi h "hp> rmmV^py f~ ATM 

Wl 111 L 11C J. 1 LJ. 1 1 Liu ~ -L <~J i- nlrl 

cells sent in 
accordance with /El/ . 




Packets 
received 
(pr) 


Cells 
received 
(cr) 


The packets received 
field (rtp/pr) is 
populated with the 
number of ATM cells 
received in accordance 
with /El/. 




Packets 
lost 
(pi) 


Cell loss 
(cl) 


The packets lost field 
(rtp/pl) is populated 
with the number of ATM 
cells lost in 
accordance with /El/. 




Jitter 
(jit) 


Jitter 
(jit) 


The jitter field 
(rtp/jit) is populated 
with the interarrival 
jitter in accordance 
with /El/. 




Delay 
(delay) 


Delay 
(delay) 


The jitter field 
(rtp/delay) is 
populated with the 
average cell 
transmission delay in 
accordance with /El/. 



Table I 



15 
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It was also discussed that there is defined a standard 
use of Session Description Protocol (SDP) parameters. 
As shown in Table 11(a) to 11(c) below, the invention 
further provides a mapping of SDP parameters to control 
VoATM connections using parameter values more commonly 
associated with VoIP connections. 



Table II (a) shows the Session Description Mappings for 
the Session Description Protocol. 



L/escr lptio 

n Type 


q,,k_ 

DVUJ 

Field 


VnTP 
vuir 

value 


VoATM 

mapping 




oJJr 

version 
v v— ; 


"NT / Zi 






required . 


Origin 
(o=) 


TBD 


TBD 


TBD 




session 
Name (s=) 


TBD 


TBD 


TBD 




session 
inf ormatio 
n \ -L — ) 


1 rSJJ 


1 JrSU 






URI (u=) 


TBD 


TBD 


TBD 




E — ma i 1 
address 
(e=) 


TBD 


TBD 


TBD 




phone 
number 

( P =) 


TBD 


TBD 


TBD 




connection 
info. ( c= ) 


network 
type 


IN 


ATM 


One to one 
mapping . 




address 
type 


IP4 


NSAP 


One to one 
mapping . 




Connect 

ion 
address 


<IP4 
Address > 


<NSAP 
Address > 


See Fig. 3 and the 
associated text 
regarding the IP 
and ATM address 
mapping . 


Bandwidth 
info. (b=) 


TBD 


TBD 


TBD 




time zone 
(z=) 


TBD 


TBD 


TBD 





Table 11(a) 
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Table 11(b) shows the Time Description Mappings for the 
Session Description Protocol . 



Descripti 
on Types 


SDP 
Value 


VoIP 


VoATM 
mapping 


Comment 


Session 
time (t=) 


TBD 


TBD 


TBD 




Repeat 
times 
(r=) 


TBD 


TBD 


TBD 





5 Table 11(b) 

Table II (c) shows the Media Description Mappings for the 
Session Description Protocol . 
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Descriptio 


SDP Value 


VoIP 


VoATM 
mapping 


Comment 


Media name 
v m— ; 


Media 
type 


audio 


audio 


No mapping 
required. 






video 


video 


No mapping 
required . 






Applicat 
ion 


applicat 
ion 


No mapping 
required . 






Data 


data 


No mapping 
required. 






control 


control 


No mapping 
required . 




Transport 
port 


<port> 


<eecid> 


See Fig. 4 and the 
associated text 
regarding the port 
and EECID mapping. 




Transport 
protocol 


RTP/AV 


AAL1/ATM 
F 






Media 
format 


0 


0 


No mapping 
required for this 
value. 0 

represents u- law 
encoded 8K 
channel . 


Media 
title (1=) 


TBD 


TBD 


TBD 




Connection 
info. (c=) 


TBD 


TBD 


TBD 




Bandwidth 
info. (b=) 


TBD 


TBD 


TBD 





Table 11(c) 



5 SDP further includes address and port information. Since 
other protocols, such as ATM in the present example, have 
a different structure for the addresses and port 
information, the present invention maps the address, or 
port, for SDP into an area of an ATM address, or port. 

10 As will be discussed further with respect to steps 204 

and 206, the invention translates the SDP address or port 
into a suitable form for insertion into the ATM address 
or port. The manner in which the invention chooses the 
suitability of the address structure will be explained in 

15 the discussion of the Figures 3 and 4 . 



10 
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Figure 3 illustrates how IP address information 
transported in SDP connection data is mapped to the 
equivalent SDP ATM address format (and vice versa) . 
5 Subsequently, this information is translated to an ATM 

End System Address (AESA) used in UNI signaling messages. 

In general, the mapping is based on virtual addressing 
overlay as generally indicated by the reference numeral 
10 302 whereby a private addressing scheme 304 is overlayed 
over the public addressing scheme 3 06 used by the ATM 
infrastructure. This method ensures that the mapping is 
segregated and is applicable to any public addressing 
scheme previously adopted by the ATM infrastructure. 

15 

In this particular example, the proposed ATM addressing 
redefines the Network Prefix field 308 of the E.164 ATM 
format (AFI=0x45) of the Private ATM address 310. The 
area of interest is the 24 digits (8 octets) 312 

20 following the Authority and Format Identifier (AFI) field 
314. This area is composed of three fields; the E.164 
address itself 316, the Routing Domain (RD) 318 
specifying a unique domain within the addressing scheme 
in use and the Area 320 identifying a unique area within 

25 the routing domain in use. 

The invention redefines these three fields into a private 
mapped IP/ATM address 310. This 24 digits (8 octets) 
address would be subdivided into two fields; a 12 digits 

30 (6 octets) prefix ( x 000000000000 ' ) isolating this overlay 

virtual space from the AESA addressing scheme used by the 
ATM infrastructure and a second 12 digits (6 octets) 
field holding the end-point IP address of the form 
* xxx . yyy . z z z . ddd 9 . Of course, this is merely an example 

35 and other address configurations are also possible. 
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It shall be appreciated that the present invention, 
maintains an ATM addressing scheme that does not violate 
standard ITU or ATM Forum addressing rules. Of course, 
it shall be understood that the present invention covers 
5 also a mapping that does not necessarily violate an ITU 
standard. 

Returning now to the flow diagram of Figure 2, the 
private address 202 is translated into a signal suitable 
10 for insertion into the public address of the ATM protocol 
in step 204. For example, the SDP address is translated 
into the format xxx . yyy . zzz . ddd such that the translated 
address fits bit-wise within the area designated by the 
mapping . 

15 

In step 206, the translated address is inserted into the 
ATM protocol of the second protocol according to the 
mapping. This address will be used later in the control 
of the bearer connection. 

20 

Figure 4 shows how the invention maps an IP port 
information transported in SDP media data to equivalent 
EECID information (and vice versa) . As shown, a port 
number 402, for example, 1234678, is translated into an 

25 EECID format 404. This format is then mapped into the 
transport mechanism 4 06, for example, a Generic 
Identifier Transport (GIT) . In the example shown in the 
Figure, the port is mapped into the user data portion 408 
of the GIT occurring after the ID, flags and length of 

30 the Identifier. Subsequently, this information is 

inserted into the GIT and transported, whereby it is 
later used in UNI signaling messages. 

Now with respect to Figure 2, in step 208, the 
3 5 information inserted into the ATM protocol is transmitted 
to the bearer connection. Thereafter, it is extracted 
according to the mapping and used to control the bearer 
connection . 



12 
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A better understanding of the invention shall be obtained 
in consideration of Figure 5, in which there is shown a 
block diagram of the system of the invention. A calling 
5 side, or ingress PSTN (I-PSTN) 502, that establishes a 
call, is coupled to a calling side media gateway 504, a 
so-called ingress media gateway (IMG) . The I-PSTN 502 
may communicate with the IMG 504 via time division 
multiplexing (TDM), for example. 

10 

On the receiving, or terminating, side is an egress PSTN 
(E-PSTN) 506, which receives the call. The E-PSTN 506 is 
coupled to a terminating side media gateway 508, or a so 
called egress media gateway (EMG) . The IMG 504 
15 communicates with the EMG 508 via the IP network 510. Of 
course, the I-PSTN and E-PSTN 502, 506 may be any type of 
communication network. Similarly, the network 510 may be 
other than an IP network. 

20 The call signaling is controlled by a switch 512, such as 
the soft switch earlier mentioned. Part of the switch 
512 may be a packet manager 514, which, at the control of 
the switch 512, packetizes and transmits signaling 
information to the media gateways 504, 508, to be 

25 explained later. 

It shall be recognized that the system of Figure 5 is 
similar to a traditional call signal connection of VoIP 
virtual trunking calls originating and terminating at 
30 traditional class 5 switches traversing an IP a packet 

network. As such, the gateway control protocol signaling 
selected for this example is Megaco (although MGCP could 
equally have been used.) 

35 The present invention, in one aspect, adds the mapping 
and translating functionality to the media gateway, or 
gateways as the case may be. With which, the 
functionality performs translations between VoIP and 
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VoATM control information based on mappings defined in 
this document. The functionality should also perform 
supporting functions such as detecting that a translation 
is required and insert ing/extract ing the messages. The 
5 entity performing this functionality will be hereafter 
referred to as the Vertical Interface Translation 
Function (VITF) . 

Figure 5 illustrates the call signaling traffic 521 - 533 
10 between the various elements in the system, which also 
may be thought of as steps of a call flow diagram. In 
step 521, a call is initiated at, for example, a class 5 
office at the I-PSTN 502. The I-PSTN normally transmits 
a signal to the switch 512, typically an SS7 I AM signal. 
15 In step 522, the switch 512, through the packet manager 
514 returns an add control message (ACM) to the I-MG 504 
to add a call. In step 523, the VITF parses the add 
control command and determines that translation is 
necessary. In response, the VITF builds a reply message 
20 with an address for routing the call and the IMG 504 
sends the message to the packet manager 514. In 
addition, the VITF translates a call control block 
provided by the calling side into an IP port number. 

25 On the receiving side, in step 524, the switch 512 sends 
an I AM message to the E-PSTN 506 to signal an incoming 
call. In step, 525, the packet manager constructs an add 
control message for adding a terminating call, which 
includes the address and port information constructed by 

30 the calling side VITF, and sends the message to the EMG 
508. In step 526, the EMG 508, which may be provided 
with its own VITF, determines that the incoming call is 
to be translated. In response, the receiving side VITF 
translates the information from the incoming message into 

3 5 an equivalent receiving side protocol. 

Next, the invention provides the remaining handshaking 
protocol to complete the call. For purposes of example, 
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the protocol for SS7 shall be used in this example, 
although other protocols are certainly within the scope 
of the invention. In step 527, an SS7 COT message is 
sent to the switch 512. In step 528, the E-PSTN 506 
5 returns an ACM SS7 message to the switch 512, for 

example. The switch, via the packet manager 514, in step 
52 9 sends a modify message to the IMG 504 with connection 
information from the receiving call side. In step 530, 
the IMG 504 returns an acknowledge signal to the switch 
10 512, via the packet manager 514. In step 531, the switch 
512 sends an ACM message to the IPSTN 502. 

When an off -hook condition is detected at the receiving 
call side as in step 532, the EPSTN 506 sends an SS7 ANM 
15 message to the switch 512 indicating a call is received. 
The switch 512 then informs the IPSTN 502 that the call 
is received and the call is completed and a 2 way bearer 
channel is set up. 

2 0 A more concrete example of the invention shall now be 
discussed with reference to Figures 6A and 6B, which 
respectively show the system and corresponding flow 
diagram of the present invention. In Figure 6A, there is 
shown a 2 way bearer connection 600, in which the IMG 602 

25 connects to the EMG 604 via respective switch routers 606 
and 608. The switch 610, which orchestrates the control 
signaling, is shown here generally as 610. 

After a call is initiated in the ingress PSTN (IPSTN) and 
30 an SS7 I AM message is signaled to the switch 610, an add 
control message to add the call is sent from the switch 
to the IMG 602 in step 612. As an example of such an add 
control message, the following code is provided, although 
certainly another message that has a similar function is 
35 within the scope of the invention. 
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MEGACO/1 [165.218. 245 . 
TRANSACTION=2363 { 
CONTEXT = $ { 

ADD = T01/02/03/04 
MEDIA { 

LOCALCONTROL { 



ADD = $ ( 
MEDIA { 

LOCALCONTROL { 
LOCAL { 

C=IN IP4 $ 

m=audio $ RTP/AVP 0 



17] :20003 
{ 

MODE = SENDONLY } 
MODE = RECE I VEONLY } , 



In step 613, the IMG 602 on parsing the message detects 
that the second Add command in the message is for an IP 
termination. The IMG 602 checks its local configuration 
information and detects that the local packet network is, 
for example, an ATM network and so parameter translation 
is required. The VITF translates the SDP session and 
media parameters contained in the message according to 
the mappings heretofore described. 



An ATM address is selected for routing of the backward 
ATM call based on configuration information typically 
provided by an ATM interface group. The VITF translates 
this address to an equivalent IP address, such as 
111.222.333.444 in the exemplary Figure, according to the 
mappings described . 



A local call control block is selected to handle the 
call, for example 12345678. This call control data 
(signaled in a VoATM call as an EECID) is translated to a 
port number by the VITF according to the mappings. 
Ultimately this call control data is returned to the IMG 
602 as a UNI GIT IE and used to locate the call control 
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block once when an ATM UNI SETUP message is received. The 
IMG 602 responds to the switch 610 with a reply signal, 
such as the following code. 

5 MEGACO/1 [MediaGatewayl] :2 000 

Reply = 2363 { 
Context = 1 { 

Add = T01/02/03/04 , 
Add = A4444 { 
10 Media { 

Local { 

v=0 

c=IN IP4 111.222.333.444 
m=audio 12345678 RTP/AVP 0 

20 

After the switch 610 sends an SS7 I AM message to the 
EPSTN 604 (step 524, Figure 5), the switch sends an add 
message to the EMG 508 to add the receiving side call in 
step 615. For purposes of example, the message may be 
25 constructed as follows: 

MEGACO/1 [165.218.245.117] :20003 
TRANSACTION=23 64 { 
CONTEXT = $ { 

ADD = T05/06/07/08 { 
3 0 MEDIA { 

^ LOCALCONTROL { MODE = SENDRECE I VE } 

ADD = $ 

3 5 MEDIA 

LOCALCONTROL { MODE = SENDRECE I VE } , 
LOCAL { 

v=0 

C=IN IP4 $ 

4 0 m=audio $ RTP/AVP 0 

REMOTE { 

v=0 

c=IN IP4 111.222.333.444 
45 m=audio 12345678 RTP/AVP 0 
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In step 616, a UNI setup message is forwarded from the 
EMG 604 to the IMG 602 UNI through the switches 606, 608. 
The setup message includes the call control data inserted 
into the UNI GIT IE. The IMG 602 uses the data to locate 
5 the call control block once when an ATM UNI SETUP message 
is received. A call proceeding message is sent from the 
IMG 602 to the switch in step 617 and, similarly, from 
switch 608 to the EMG 604. In step 618, a UNI connect 
message is returned from the ATM network to the EMG 604 
10 through the switches 606, 608. In this manner, a 2-way 
ATM - TDM interworking bearer path is setup through the 
EMG 6 04. 

In step 619, the EMG 604, i.e., the VITF of the EMG, 
15 parses the message and detects that the second Add 

command in the message is for an IP termination. The EMG 
checks its local configuration information and detects 
that the local packet network is, for example, an ATM 
network and so parameter translation is required. The 
20 VITF translates the SDP session and media parameters 

contained in the message according to, for example, the 
mappings heretofore defined. 

More specifically, the IP address (111.222.333.444) 
25 received in the remote descriptor SDP connection data is 
translated by the VITF to an equivalent address, for 
example, an ATM address, according to the exemplary 
mappings defined. This address data is used to populate a 
Called Party Address IE of the ATM UNI SETUP message sent 
3 0 by the EMG 6 04 in order to initiate a backward connection 
of ATM SVC. 

Furthermore, the VITF translates the port number received 
in the remote descriptor media name data (i.e., 12345678) 
35 according to the mappings. This data is used at the EMG 
604 to populate the Generic Information Transport IE in 
the ATM UNI SETUP message. 
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Once the ATM UNI CONNECT message is returned from the ATM 
network and a 2 -way ATM - TDM interworking bearer path 
has been setup through the EMG 604 then the a message, 
such as the example message below, is returned to the 
switch 610. 



MEGACO/1 [MediaGatewayl] :2 000 
Reply = 2364 { 
Context = 2 { 

Add = T05/06/07/08, 
Add = A5555 { 
Media { 
Local { 

v=0 

c=IN IP4 555.666.777.888 
m=audio 8 9ABCDEF RTP/AVP 0 

} 

} 

} 

} 

} 



In step 62 0, an SS7 COT message is forwarded by the 
switch 610 to the EPSTN 506. In step 621 The E-PSTN 
returns an acknowledge signal in the form of an ACM SS7 
message . 



As explained in reference to Figure 5, the invention 
performs the remaining handshaking. A modify message in 
step 529 is sent from the switch to the IMG 504. The 
message for example purposes may be provided as follows. 



MEGACO/1 [165.218.245.117] :20003 
TRANSACTION=23 6 5 { 
CONTEXT = 1 { 

MODIFY = T01/02/03/04 { 
MEDIA { 

LOCALCONTROL { MODE = SENDRECE I VE } 

MODIFY = A4444 { 
MEDIA { 
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LOCALCONTROL { MODE = SENDRECE I VE } , 
REMOTE { 

v=0 

c=IN IP4 555.666.777.888 
5 m=audio 8 9ABCDEF RTP/AVP 0 



It shall be appreciated that, in this particular example, 
the IP address (555.666.777.888) received remote 
descriptor SDP connection data is not used by the IMG 504 
15 for signaling purposes and so no translation is required. 
Similarly the port number (89ABCDEF) received in the 
remote descriptor media name data is not required and so 
again no translation is required. 



20 At this time, a 2 -way ATM - TDM interworking bearer path 
is essentially setup through the IMG 504. In step 530 an 
acknowledge signal, such as that provided below, is 
returned to the switch. 



25 MEGACO/1 [MediaGatewayl] :2000 

Reply = 23 65 { 
Context 1 { 

Modify = T01/02/03/04, 
Modify = A4444 

30 } 
} 



The remaining signaling executed upon an off -hook 
condition to establish the call has already been 
35 discussed with reference to Figure 5. 



The invention further provides for the removal, or tear- 
down, of the call once a call is ended. The steps for 
tear-down will be discussed in reference to the flow 
40 diagram 700 of Figure 7. In step 702, the I-PSTN signals 
an SS7 REL to the switch 610 initiating the tear-down of 
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the call. The switch 610 sends subtract message to the 
IMG 602, such as that shown here. 

MEGACO/1 [165.218.245.117] :20003 
TRANSACTION=23 6 6 { 
CONTEXT = 1 { 

SUBTRACT = T01/02/03/04 , 
SUBTRACT = A4444 { 

AUDIT { STATISTICS } 



In step 704, the IMG 602 initiates the clearing of the 
ATM SVC. Call statistics data is located and translated 
by the VITF at the IMG 602 according to the exemplary 
mappings defined above. Once the interworking bearer path 
is torn down the IMG 602 returns the reply message to the 
switch, such as follows. 

MEGACO/1 [MediaGatewayl] :2000 
Reply = 2366 { 
Context = 1 { 

Subtract = T01/02/03/04 , 
Subtract = A4444 { 
Statistics { 

rtp/ps = 1234, 
nt/os = 56749, 
rtp/pr = 10000, 
nt/or = 984726, 
rtp/pl = 34.90, 
rtp/jit = 9, 
rtp/delay = 2 9 



Next, the receiving side is torn-down. In step 706, the 
switch sends a subtract message to the EMG 604, which may 
be the following. 

MEGACO/1 [165.218.245.117] :20003 
TRANSACTION=23 6 7 { 
CONTEXT = 2 { 

SUBTRACT = T05/06/07/08, 
SUBTRACT = A5555 { 

AUDIT { STATISTICS } 
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In step 708, Call statistics data is located and 
translated by the VITF at the EMG 6 04 according to the 
predefined mappings. Once the interworking bearer path is 
torn down, the EMG 6 04 returns the reply message to the 
switch 610, such as given by the following reply message 
example . 

MEGACO/1 [MediaGatewayl] :2000 
Reply = 2367 { 
Context = 2 { 

Subtract = T05/06/07/08 , 
Subtract = A5555 { 
Statistics { 

rtp/ps = 4321, 
nt/os = 647290, 
rtp/pr = 5000, 
nt/or = 836193, 
rtp/pl = 45.78, 
rtp/jit = 10, 
rtp/delay = 34 



} 

} 

Thus, the call is torn down and the network resumes 
operation, ready for the next call initiation. 



While the present invention has been described in the 
context of a specific example, it shall be appreciated 
that the invention is not so limited to a single example, 
but that similar embodiments and variations are within 
the scope of the invention. The invention encompasses 
not only the IP and ATM protocols, but any mapping from 
one protocol to another. The specific code provided is 
for example only and other code which provides the same 
function is certainly within the invention. The present 
invention proposes a standards based solution that can be 
employed in multi vendor networks a primary motivation, 
but the invention need not be standards based. 



